-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add and improve operations on BufferSources #987
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Glad to see ABs and TAs having more solid foundations here!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
I wonder how I would use this for https://encoding.spec.whatwg.org/#dom-textencoder-encodeinto.
Part of the problem I guess is https://heycam.github.io/webidl/#dfn-get-buffer-source-reference not being very clear. Perhaps we should aim to replace that completely by having a copy operation that returns a byte sequence? And instead of obtaining a reference you'd use the algorithms you have here (though we'd need to add write for views).
Oh yeah, I like the idea of getting rid of "get a reference" in favor of having people write directly into it. And then making the "get a copy" operation more detailed using this same sort of primitive. I'll investigate. |
a6bf834
to
fce17fd
Compare
OK, I expanded and updated this PR's scope a bit. The OP has been edited with more details. A re-review would be lovely! I will work on an Encoding spec PR to show how the "write" concepts would be used. |
Encoding wants this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm modulo the [[Realm]] question for ABs.
index.bs
Outdated
1. Let |arrayBufferData| be |arrayBuffer|.\[[ArrayBufferData]]. | ||
1. Let |arrayBufferByteLength| be |arrayBuffer|.\[[ArrayBufferByteLength]]. | ||
1. Perform [=?=] [$DetachArrayBuffer$](|arrayBuffer|). | ||
1. If |realm| is not given, let |realm| be |arrayBuffer|.\[[Realm]]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think ABs have a [[Realm]], only functions do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, right. I guess that is why streams uses the current Realm. Probably that's the right fallback here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They do have a realm per IDL, see https://heycam.github.io/webidl/#dfn-associated-realm. See also tc39/ecma262#1333.
Can I get an editor review? I'm not sure merging this will work given the travis-ci.org shutdown, but I think we should at least try. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestions for a few more concepts to define:
- BufferSource/is detached: basically an IDL version of IsDetachedBuffer that also supports views.
- ArrayBufferView/get the underlying ArrayBuffer: spares specs from having to step into ES land in order to transfer the input buffer.
- (possibly) ArrayBufferView/transfer
Is "get a reference to the bytes held by the buffer source" used anywhere? |
I added BufferSource/is detached for now. On the others, it occured to me that we have two directions here: super-polymorphism, where everything is defined on BufferSources, or something more true to the model where ArrayBuffers are special. I was curious for your thoughts. Super-polymorphism:
ArrayBuffers are special:
The one place I was aware of was Encoding. But I just thought to check a bit more and Web Audio is a heavy consumer. I should prepare a PR for them before we merge this. |
I think it's fine to to go with "super-polymorphism" as long as those algorithms are appropriately detailed. I don't really see a downside in terms of what is possible (especially since we can provide a way to get the underlying buffer once we identify a need for that) and it makes it easier to write prose. It also shouldn't get in the way of #865 which is still something we need to do I think. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the others, it occured to me that we have two directions here: super-polymorphism, where everything is defined on BufferSources, or something more true to the model where ArrayBuffers are special. I was curious for your thoughts.
Here's an alternative: super-polymorphism for read-like operations (byte length, is detached, get a copy), ArrayBuffers are special for write-like operations (create, write, detach, transfer). The name "BufferSource" is fairly explicit about being the source, so I don't think it's worthwhile to make write operations work for any BufferSource.
Come to think of it, this layout is what you have already!
We need write for all BufferSource types, no? How else would you write into a Uint8Array respecting the length and such? |
@annevk Yeah, it’s more like we define it separately from ArrayBuffer so we’d have ArrayBuffer/write and ArrayBufferView/write, rather than a combined BufferSource/write. |
Alright, we'll merge, but TBD if it'll actually deploy given the Travis situation... |
Another is in WebAuthn: https://w3c.github.io/webauthn/#sctn-createCredential |
* Use new Web IDL buffer primitives See whatwg/webidl#987. * Fix #2361: Use new Web IDL buffer primitives Updates spec to use new Web IDL buffer primitives. The changes are marked as candidate corrections, but we use several correction amendments to make it easy to see what the new and old text will be. Using just one makes it super-hard to figure out what controls the text, and the text sometimes doesn't always clearly show what's deleted and what's inserted because the links are colored correctly, and struck-through text doesn't strike through links. (A bikeshed issue?) * Remove link that no longer exists * Update changelog * Add script to create list of corrections for a change * Add comments * Change text slightly Change "write" to "allow writing into" so reflects better what getChannelData allows. * Add links to the previous and next change in the amendment box. * Inline the JS file * Fix up script and add event listener Fix up the script so bikeshed doesn't mangle it. Add an onload event listener so that when the doc is loaded we can run ListAmendments to add a list of the related changes for the change log. * Fix typo * Inline JS into index.bs Adjust so bikeshed doesn't mangle it. Move the listener code into the same script segment so it's easy to find. * Add some comments * Refine markup * The changes should should have the "proposed" class too. * Update text to say "Proposed", as shown in https://fantasai.inkedblade.net/style/design/w3c-restyle/2020/readme#proposed-changes * Update buttons to say "Previous Change" and "Next Change" to make it clearer what the buttons do. * Refine amendment boxes * Limit the scope of each change to a paragraph or item in an algorithm. * Move the changed section to be in the `<div>` for the amendment box to it's easier to see where the changes could be. * Fix bad numbering. The id had the correct value, but the link for the issue used the wrong change number (should be 3 instead of 2). * Remove amendents.js. Not needed because we've basically inlined it all so that the preview shows the prev/next buttons and the list of changes for the change log. Co-authored-by: Domenic Denicola <d@domenic.me> Co-authored-by: Raymond Toy <rtoy@chromium.org>
Updates to dependent specs:
I'd like review here from @syg and/or other ES editors, especially for the "write" operation.